Re: BUG #2033: Assertion Failure: File: "procarray.c",

>"Joel Stevenson" <joelstevenson@mac.com> writes:
>>  I'm running into an Assertion failure this morning w/8.1.0.  I believe it is
>>  related to using the NOWAIT flag.  Here is the log message:
>
>>  TRAP: FailedAssertion("!(serializable ? !((MyProc->xmin) != ((TransactionId)
>>  0))
>>   : ((MyProc->xmin) != ((TransactionId) 0)))", File: "procarray.c", Line:
>>  492)
>
>With no stack trace, and no information about how to reproduce the
>error, I'm afraid this report is just about useless :-(

gdb's 'bt' on one of the core files produces:

#0  0x00138eff in ?? ()
#1  0x0017ec8d in ?? ()
#2  0x00246cd8 in ?? ()
#3  0x00000000 in ?? ()

the backtrace in various other of the 17 core files looks exactly the same.

I am not a C programmer but am happy to try to dig up any information
I can from the core files, but will need instruction from someone
wiser in the ways of gdb than I.  :)

My second email provided more detail about what PG is being used for
and what was happening when the assertion failure occurred.  A
further description:

  * There is one process which is inserting work units into a work_queue table.
    The rate of insertion varies but can become very high.

  * There are between zero and 100 other processes which select from the
    work_queue table using SELECT ... LIMIT 1 FOR UPDATE NOWAIT.  Because of the
    where clause conditions and the LIMIT 1, these processes can and do contend
    for the same rows in the table.  When a row is retrieved it is immediately
    updated as 'claimed'.

  * Without the NOWAIT flag, the contending processes operate as
expected: either
    retrieving a row or waiting on a lock briefly and not retrieving a row
    because the first lock resulted in an update causing the match to become
    invalid.

  * At the time of the assertion failure, there where approximately 20
work_queue
    consumer processes running and the work_queue provider process was actively
    inserting new data into the table.



Here are some more log lines at the error point:

<snip>
2005-11-09 07:00:06 PST 19681 ERROR:  55P03: could not obtain lock on
row in rel
ation "WORK_QUEUE"
2005-11-09 07:00:06 PST 19681 LOCATION:  heap_lock_tuple, heapam.c:2157
2005-11-09 07:00:06 PST 19681 STATEMENT:  SELECT ID, UNIT
                         FROM WORK_QUEUE
                         WHERE
                         blah...blah...blah
                         LIMIT 1
                         FOR UPDATE
                         NOWAIT
TRAP: FailedAssertion("!(serializable ? !((MyProc->xmin) !=
((TransactionId) 0))
  : ((MyProc->xmin) != ((TransactionId) 0)))", File: "procarray.c", Line: 492)
2005-11-09 07:00:06 PST 14093 LOG:  00000: server process (PID 19681)
was termin
ated by signal 6
2005-11-09 07:00:06 PST 14093 LOCATION:  LogChildExit, postmaster.c:2426
2005-11-09 07:00:06 PST 14093 LOG:  00000: terminating any other
active server p
rocesses
2005-11-09 07:00:06 PST 14093 LOCATION:  HandleChildCrash, postmaster.c:2307
2005-11-09 07:00:06 PST 20323 WARNING:  57P02: terminating connection
because of
  crash of another server process
</snip>

the ERROR: 55P03 seems expected given the description of how NOWAIT operates.

Let me know if I can provide more information.

-Joel